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IN THE SPECIFICATION 

Please replace paragraph [0008] of the specification with the following paragraph: 

[0008] The present invention satisfies the need in the art by providing [[a]] systems and 

methods for encouraging large scale downloading to wireless devices. In one aspect of the 
present invention, a method for performing automated distribution and billing comprises 
providing an negotiation forum between a delivery entity and a receiver entity, configuring a 
catalog for the receiving entity associating the application and the metadata in a central 
repository, sending the catalog information to the receiver entity, receiving indication that a 
transaction of the product occurred, and transmitting billing information to the receiver entity. 

Please replace paragraph [0021] of the specification with the following paragraph: 

[0021] The Unified Application Management (UAM) system ICQ is a core service 

implemented, in one embodiment, as a part of the QIS Middleware. (QIS Middleware is part of 
the BREW™ BREW® architecture developed by QUALCOMM feer Incorporated , 
headquartered in San Diego, Calif, which is a larger umbrella suite of programs that includes 
other fimctions, such as authentication of certified applications.) The UAM 100 is a centralized 
suite of application management services targeted to reside in the QIS Distribution Center 
(QDC). The UAM provides the following key services relating to wireless application 
management, carrier distribution and billing, including: 

• The UAM is a central repository which manages application files and application 
metadata; 

• The UAM manages the distribution of wireless applications to carrier site 
download servers; 

• The UAM provides services to configure the distribution of applications to 
carrier sites via carrier catalog management services; and 

• The UAM manages application metadata used for accounting/billing services tiris 
data . This metadata is transmitted to the billing/accounting system 115. This 
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metadata may be transmitted directly to the billing/accounting system 1 15 or via 
the TX server 110. 

Please replace paragraph [0022] of the specification with the following paragraph: 

[0022] The Application Download Server (ADS) 105 is another core service 

implemented, in one embodiment, as part of the QIS Middleware. The ADS 105 interfaces to the 
UAM 100 for managing carrier catalog and applications to be distributed fi-om a particular 
carrier site. The UAM 100 may interface to multiple carriers and a carrier may host multiple 
ADS'. Each ADS 105 may be configured for distribution of similar or unique applications by 
using the UAM catalog management services (described below). The ADS interfaces with a 
wireless device, such as a cellular phone 120, to display the catalog of applications available for 
download and download, and enables the user to select application(s) to download. For specific 
wireless device user transactions, the ADS may log the events locally on the ADS. The ADS 
may replicate the transaction data to the Transaction (TX) server 1 10 at the QDC for 
consolidation. This consolidated transaction data will be used to derive billing and accounting 
transactions. While a phone 120 is depicted in FIG. 1, other wireless devices may be used. 

Please replace paragraph [0023] of the specification with the following paragraph: 

[0023] The catalog and application data moves from the UAM to the ADS. In one 

embodiment, the interface between the UAM and the ADS is designed as an XML file interface. 
There is no database resident or required on the ADS server. Application and catalog 
management services between the UAM and the ADS was were intentionally designed for 

lightweight servers that did not require a RDBMS (relational database). The ADS management 
logic is optimized for performing efficiency (i.e., one-pass parse of data streams). Inherent in the 
design is the capability to deploy low cost carrier download servers across worldwide carrier 
sites. 

Please replace paragraph [0031] of the specification with the following paragraph: 

[003 1] The TX "converted" transaction data is used as the "data of record" for processing 

billing related transactions (Step 420). The QDC Rating/Billing Process uses the TX "converted" 
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transaction data and the UAM billing logic, such as pricing plans, to generate the "costed" 
transaction data. This "costed" transaction data is used to generate developer payment, the 
invoices are sent to carriers for enablement services, and the carrier billing data extract file(s) 
that can be used for subscriber billing (Step 425). It will be recognized by one skilled in the art 
that the carrier billing extract data function may be performed by other components, including 
the transaction server. The derived accounts receivable (AR) and accounts payable (AP) may 
then be processed using a business appUcation, for example, PeopleSoft business software, 
which is known in the art. 

Please replace paragraph [0035] of the specification with the following paragraph: 

[0035] In one embodiment, an automated transaction collection is implemented. The 

process of automated transaction collection includes, upon successful download of an 
application, the ADS capturing the MIN, Application Name, Application ID, Purchased Plan, 
Purchase Price, and Time/Date. The ADS transmits, including by replication, data to transaction 
server at specific intervals (e.g., every 30 minutes) or more frequently, e.g., in near real time, as 
required, e.g., based on file sized exceeding a threshold. The transaction server binds transaction 
to business data. This binding process may be used to resolve part number, carrier information, 
billing parameters, parse transactions into a relational database, splits out restricted application 
transactions, and delivers restricted application raw data to carrier. 

Please replace paragraph [0039] of the specification with the following paragraph: 

[0039] Carriers then negotiation negotiate specific metadata details with the developer 

via the extranet (Step 610). For example, the developer may submit a price associated with an 
application to charge a user/subscriber of the application. The carrier, upon viewing the price, 
may reject it and submit, by sending a message or entering data into a field on the extranet, a 
price the carrier would like to associate with the application. The developer may agree or 
respond with a counteroffer. This negotiation may occur several times, all over the extranet. 
Furthermore the negotiation may occur between multiple carriers and multiple developers all 
through the extranet. This includes concurrent negotiations between multiple carrier-developer 
pairs. This provides the benefit that a developer or a carrier can go to one place to view available 
products or purchases and not have to establish unique negotiating methods or paradigms with 
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all the entities involved. In other words, the same interface and method may be used to negotiate 
different metadata between multiple entities. 
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